This review was generated by AI.

Thanks for this — the direction is right and the execution is clean: extracting a testable wpsc_parse_accept_header() helper, real RFC 7231 q-value parsing, preserved memoization and the wpsc_accept_headers filter contract, malformed/out-of-range handling, and no-DB unit tests that fit nicely into the smoke-test tier being set up in #1051. The reported New Relic Synthetics case is fixed correctly.

There's one required change before merge: the */* wildcard fallback re-introduces a deliberately-fixed Fediverse regression.

The problem

This PR was written against an earlier version of the issue brief that still credited text/html with the */* quality value. That brief has since been updated to remove it, precisely because of this case. The current code:

} elseif ( null !== $wildcard_q ) {
    $effective_html_q = $wildcard_q;
}

Trace a Fediverse fetch — Accept: application/activity+json, */*:

• html_q = null (no explicit text/html)
• wildcard_q = 1.0 → effective_html_q = 1.0
• json_q = 1.0
• 1.0 > 1.0 is false → returns text/html

The same happens for any JSON client sending Accept: application/json, */*. Because the cache only ever serves text/html (wp_cache_serve_cache_file() bails on anything else), classifying these as text/html means the client passes the serve-gate and gets handed the cached HTML page instead of being bypassed to the application — the exact problem the Accept-header handling was added to prevent. The asymmetry matters here: misclassifying an HTML-preferring request as JSON only costs a cache miss; misclassifying a JSON-preferring request as HTML serves the wrong representation.

Suggested fix

Use the explicit text/html q-value only, defaulting to 0.0 when it's absent — don't fall back to */*:

// Effective html q: explicit text/html only. A */* wildcard must not lift
// text/html above an explicitly requested JSON type, or JSON/Fediverse
// clients sending e.g. "application/json, */*" get served cached HTML.
$effective_html_q = ( null !== $html_q ) ? $html_q : 0.0;

…and drop the $wildcard_q tracking. This still fixes the New Relic case (explicit text/html;q=1.0 > application/json;q=0.9), and Accept: */* on its own still resolves to text/html because json_q is 0.0 when no JSON type is present.

Test changes

• test_wildcard_covers_html_when_not_explicit asserts the behaviour we need to remove — flip it: */*,application/json;q=0.9 should classify as application/json.
• Add a regression test: application/json, */* → application/json.
• test_explicit_html_takes_precedence_over_wildcard and a */*-alone → text/html case both still pass unchanged.

Everything else looks good to go once the wildcard handling is removed. For full background on why JSON/Fediverse traffic is kept out of the cache entirely, see the discussion on #1045.

This review was generated by AI.

The classification logic is now correct — thanks for turning it around. effective_html_q uses the explicit text/html q-value only (defaulting to 0.0), the */* fallback is gone, and test_fediverse_json_with_wildcard_classifies_as_json (application/json, */* → application/json) plus the flipped wildcard test lock in the Fediverse behaviour. No objections to the production change in wp-cache-phase2.php.

The two red checks are both test-file hygiene, not logic — all 15 assertions actually pass.

PHPUnit (PHP 8.2) — doc-comment metadata deprecation

The class-level /** @covers wpsc_parse_accept_header */ doc-comment triggers a PHPUnit deprecation, and both phpunit.11.xml.dist and phpunit.12.xml.dist set failOnPhpunitDeprecation="true". The "only 8.2 fails" puzzle is a PHPUnit-version split: on 8.2 composer downgrades to PHPUnit 11, which still reads doc-comment metadata and emits the deprecation → exit 1; on 8.3+ it uses PHPUnit 12, which ignores doc-comment metadata entirely, so no deprecation fires. The run log confirms it: OK, but there were issues! Tests: 15, Assertions: 15, PHPUnit Deprecations: 1.

Fix: replace the @covers doc-comment with the attribute, which works on both 11 and 12 and matches the repo's existing Jetpack.PHPUnit.Attributes sniff:

use PHPUnit\Framework\Attributes\CoversFunction;

#[CoversFunction( 'wpsc_parse_accept_header' )]
class WpscParseAcceptHeaderTest extends TestCase {

PHPCS — 7 errors, all in tests/php/WpscParseAcceptHeaderTest.php

1. "A file should either contain function declarations or OO structure declarations, but not both." The apply_filters() stub function collides with the test class. wpsc_parse_accept_header() (the function under test) doesn't call apply_filters, so the stub is probably unnecessary; if requiring wp-cache-phase2.php turns out to need it, move it into tests/php/bootstrap.php. Either way the test file should contain only the class.
2. Missing @var tag on the $json_types property docblock.
3. The four // method comments (the wildcard-behaviour notes) need to be /** ... */ docblocks.
4. One doc-comment short description starts lowercase ("application/activity+json classified…") — capitalize it.

Minor

The comment in test_malformed_q_value_treated_as_default still says "effective html_q from */*=0.7" — leftover from the old wildcard logic. The assertion is correct, but the reasoning should read "html absent → effective_html_q = 0.0; json q=1.0 > 0.0 → application/json."

Once the @covers becomes an attribute and the PHPCS items are cleared, this should go green. Logic LGTM.